Guideline: CRUD

The data that are stored and maintained in the system under test have a life cycle. This starts when an entity is created and ends when it is removed. In between, the entity is used by updating it or consulting it.

An overview of the life cycle of the data, or entities, is obtained with the aid of a “CRUD matrix”. This is a matrix in which the entities are shown horizontally on the axes and the functions vertically. The matrix is filled in using the letters C(reate), R(ead), U(pdate) and D(elete). If a function executes a particular action in connection with an entity, this is shown in the matrix by means of a C, R, U and/or D. This is illustrated in figure 1.

	Invoice	Article	…
Management of articles	-	C, U, D	…
Create invoice	C	R	…
Desk payment	C, R, D	-	…
…	…	…	…

Figure 1: Example of a CRUD matrix.

Creating a CRUD matrix

In order to create the CRUD matrix, all the functions in the system are reviewed. For each recognised function, one needs to determine:

Which entities are used by this function
Which actions (C, R, U and/or D) are carried out on these entities.

The result of this is entered in the matrix.

Often, a special structure is visible that is connected with 2 groups of data and of functions:

Master data with management functions - Master data are the basic data in the system. For example, “article” and “customer”. They are usually maintained independently of the other data with the aid of the management functions linked to them. This generally has the following effect on the CRUD matrix: with a management function, only the column for the relevant master data is completed, and with all the actions: C, R, U and D. If the master data and management functions are defined first (and in the same sequence) in the CRUD matrix, this part of the CRUD matrix will be filled in solely on the diagonal (with “CRUD”)
Derived data with processing functions - Derived data are data that are produced by the specific business processes, in which master data is used. For example, “Quote” and “Invoice”. It is the processing functions that manage the specific business processes and produce and amend the derived data. This generally has the following effect on the CRUD matrix: processing functions only execute the action “R” on the master data. All the actions can be carried out on the derived data. With the derived data, the management function rows are empty. All the actions (C, R, U and D) are carried out by 1 or more processing functions.

In practice, it is of course permitted to deviate from this, but the reason for doing so would at least merit investigation.

The use of the CRUD matrix is preferably not delayed until during the testing, but should be delivered as part of the system development by the developer, for the creation of a CRUD matrix is not only useful to testers, but also to the developers themselves: the designing of an information system is usually reasoned from within the functions. Per function, it is described which data will be used. In the creation of a CRUD matrix, reasoning takes place from within the data. Per entity, it is described which functions will use the relevant entity in which way. By creating such a cross-reference table (CRUD matrix) anomalies and/or incomplete areas are sometimes brought to light that would probably not be found with a function-orientated approach, whereas they are now found at an early stage.

Testing the life cycle

The testing of the life cycle consists of 2 parts: the completeness check and the consistency test. These are explained below:

Completeness check

This is a static test, in which it is examined in the CRUD matrix whether all 4 possible actions (C, R, U and D) occur with every entity. In other words, has the entire life cycle been implemented for every entity? The lack of an action does not necessarily mean that the system is wrong. However, the reason for it at least requires investigation.

Consistency test

This is a dynamic test aimed at integration of the various functions. This checks whether the various functions use an entity in a consistent way. In other words, is the relevant entity being corrupted by one function in such a way that it can no longer be used by the other functions correctly?

Test cases are derived by putting together an entire life cycle of an entity. This is done as follows:

Every test case starts with a “C”, followed by all the possible “U”s and ending with a “D”. If there are further possibilities of creating or removing an entity, additional test cases are designed.
After every action (C, U or D), an “R” is carried out once or more. This is to establish that the entity has been correctly processed and is usable for the other functions (has not been corrupted)
In respect of the relevant entity, all the occurrences of actions (C, R, U and D) in all the functions should be covered by the test cases

With this, CRUD is fully covered in principle.

More thorough coverage of CRUD can be achieved by requiring that combinations of actions also be fully covered. For example, by requiring that after each “U” all the functions with an “R” should be carried out. The example below illustrates this:

Suppose that the entity “Order” is processed as follows by the following functions:

Create order (C);
Cancel order (D);
Part-delivery (U);
Overview of orders (R);
Stock control (R)

The standard coverage of CRUD is then achieved with the following test case:

Create order (C)
Stock control (R)
Part-delivery (U)
Overview of orders (R)
Cancel order (D)
Overview of orders (R)

However, with this, the following fault would not be found: after a part-delivery, the stock control is no longer correct, because it is (wrongly) treating the whole order as having been delivered. This fault would have been found with the more thorough variant, which gives the result with the following test case:

Create order (C)
Overview of orders (R)
Stock control (R)
Part-delivery (U) (Causes fault in “Stock control”)
Overview of orders (R)
Stock control (R) (Fault is found)
Cancel order (D)
Overview of orders (R)
Stock control (R)